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INTERVIEW AGENDA 

(1 ) Explain the problem solved 

(2) Analyze the claimed solution 

(3) Analyze all cited art 

(4) Explain why all claims are allowable in view of the cited prior art 

Present Status of Case 

Tlnis Agenda for a telephonic interview with Examiner Colan is sent in response 
to the FINAL Office Action mailed by USPTO on January 5, 2010- 



• This Agenda for the telephonic interview is sent via facsimile: 

o Facsimile # (571)-273-2752 
o Telephone # (571)-272-2752 

• At Examiner's earliest convenience, please call Attorney Michael T. Abramson 
(Reg. No. 60,320) at 617-951-3053 to schedule the telephonic interview. Thank 
you in advance for your time. 
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TN THE CLAIMS : 

1. (Previously Presented) A method for establishing identity in a file system, 
comprising: 

receiving, from a client, a first Network File System (NFS) operation concerning 
an indicated file, the first NFS operation received by a proxy; 

forwarding the first NFS operation from the proxy to be received by a file server; 

returning a NFS file handle associated with the first NFS operation from the file 
server to the proxy in response to the file server receiving the first NFS operation from 
the proxy; 

inserting, by the proxy, metadata into the NFS file handle in response to receiving 
the NFS file handle from the file server, wherein the metadata is an encryption key; 

sending, by the proxy in response to receiving the NFS file handle from the file 
server, the NFS file handle with the metadata inserted in the NFS file handle to the client 
as a reply to the first NFS operation; and 

vising, by the client, the metadata and the NFS file handle in a second NFS 
operation to identify the client and the indicated file. 



1 2. (Previously Presented) The method of Claim 1 , whereby using the metadata in the 

2 NFS file handle eliminates a need for the proxy to generate additional requests to the file 

3 server to establish file identity, and for completing client requests. 

1 3. (Previously Presented) The method of Claim 1 , further comprising: 

2 encoding metadata in a form of a session key into the file handle, the session key 

3 expiring after a predetermined amount of time. 

1 4. (Previously Presented) The method of Claim 1, further comprising: 

2 using an NFS file system as the file system . 

1 5. (Previously Presented) The method of Claim 1, further comprising: 

2 using a stateless protocol by the file system . 
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i 6-29. (Cancelled). 

1 30. (Previously Presented) The method of claim 1 , further comprising: 

2 receiving, from the client, a second NFS operation by the proxy, the second NFS 

3 operation comprising the metadata in a further NFS file handle sent with the second NFS 

4 operation; 

5 identifying, in response to the metadata, the client as having a permission to 

6 submit the second NFS operation; 

7 sending the second NFS operation to the file server and not sending the metadata 
g with the second NFS file handle to the file server; and 

9 receiving by the proxy a further NFS reply from the file server, and sending by 

10 the proxy the further NFS reply to the client. 

1 31. (Previously Presented) A method for efitabhshing identity in a file system, 

2 comprising: 

3 receiving a first file request concerning an indicated file from a client, the first file 

4 request received by a proxy; 

s forwarding the first file request from the proxy to a file server; 

6 returning a reply associated with the first file request from the file server to the 

7 proxy, wherein the reply includes a file handle associated with the indicated file; 
g inserting, by the proxy, metadata into the file handle; 

0 sending, by the proxy, the file handle with the metadata inserted in the file handle 

10 to the client, the metadata to be used in further requests to identify the client as having a 

1 1 permission to access the indicated file; 

12 receiving, from the client, a second file request by the proxy, the second file 

1 3 request including the metadata in a second file handle sent with the second file request; 

14 identifying, in response to the metadata, that the client has the permission to 

15 submit the second file request; 

1 e sending the second file request to the file server and not sending the metadata 
1 7 with the second file handle to the file server; and 

3 
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lg receiving by the proxy a second reply from the file server, and sending by the 

1 9 proxy the second reply to the client. 

1 32. (Previously Presented) An apparatus to establish identity in a file system, 

2 comprising: 

3 a proxy configured to receive a first Network File System (NFS) operation 

4 concerning an indicated file sent by a client to the file system, the proxy further 

5 configured to forward the first NFS operation to be received by a file server; 

6 the file server configured to return a NFS file handle associated with the first NFS 

7 operation to the proxy in response to the file server receiving the first NFS operation 
s from the proxy; 

') the proxy further configured to insert metadata into the NFS file handle in 

i o response to receiving the NFS file handle from the file server, wherein the metadata is an 

n encryption key; and 

1 1 the proxy further configured to send the NFS file handle with the metadata 

i 3 inserted in the NFS file handle to the client as a reply to the first NFS operation, the 

H metadata and the NFS file handle to be used in a second NFS operation to identify the 

is client and the indicated file. 

1 33. (Previously Presented) The apparatus as in claim 32, further comprising: 

2 the proxy further configured to receive, by the client, a second NFS operation, the 

3 second NFS operation comprising the metadata in the second NFS file handle sent with 

4 the second NFS operation; 

5 the proxy to identify, in response to the metadata, the client as having a 

6 permission to submit the second NFS operation; 

7 the proxy to send the second NFS operation to the file server and not to send the 
9 metadata with the second NFS file handle to the file server; and 

9 the proxy to receive a second NFS reply from the file server, and the proxy to 

10 send the second NFS reply to the client. 

4 
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34. (Previously Presented) The apparatus of Claim 32, further comprising: 

the proxy to use the metadata in the NFS file handle received from the client to 
eliminate a need for additional communication with the file server to establish file 
identity. 

35. (Previously Presented) The apparatus of Claim 32, further comprising: 

the proxy to encode the metadata in a form of a session key into the NFS file 
handle, the session key expiring after a predetermined amount of time. 

36. (Previously Presented) The apparatus of Claim 32, further comprising: 

an NFS file system used as the file system. 

37. (Previously Presented) The apparatus of Claim 32, further comprising: 

a stateless protocol used by the file system. 

38. (Previously Presented) A non-volatile memory executed on a computer, comprising: 

the non-volatile memory containing procedures for execution on the computer for 
a method of establishing identity in a file system, the method having the steps of, 

receiving, from a client, a first Network File System (NFS) operation concerning 
an indicated file, the first NFS operation received by a proxy; 

forwarding the first NFS operation from the proxy to be received by a file server; 

returning a NFS file handle associated with the first NFS operation from the file 
server to the proxy in response to the file server receiving the first NFS operation from 
the proxy; 

inserting, by the proxy, metadata into the NFS file handle in response to receiving 
the NFS file handle from the file server, wherein the metadata is an encryption key; and 

sending, by the proxy in response to receiving the NFS file handle from the file 
server, the NFS file handle with the metadata inserted in the NFS file handle to the client 
as a reply to the first NFS operation; and 
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using, by the client, the metadata and the NFS file handle in a second NFS 
operation to identify the client and the indicated file. 

39. (Previously Presented) A method for establishing identity in a file system, 
comprising: 

receiving a first file request concerning an indicated file from a client, the First file 
request received by a proxy; 

forwarding the first file request from the proxy to a file server; 

granting a permission for the request to be acted upon by the file system in 
response to a predetermined protocol; 

returning a reply associated with the first file request from the file server to the 
proxy, wherein the reply includes a file handle associated with the indicated file; 

inserting, by the proxy, a session key into the file handle; and 

sending, by the proxy, the file handle with the session key inserted in the file 
handle to the client, the session key to be used in further requests to identify the client 
and the indicated file. 

40. (Previously Presented) The non-volatile memory of Claim 38, further comprising: 

receiving, from the client, a second NFS operation by the proxy, the second NFS 
operation comprising a session key in a second NFS file handle sent with the second NFS 
operation; 

identifying, in response to the session key, that the client has the permission to 
submit the second NFS operation; 

sending the second NFS operation to the file server and not sending the session 
key with the second NFS file handle to the file server; and 

receiving by the proxy a second NFS reply from the file server, and sending by 
the proxy the second NFS reply to the client. 

41 . (Previously Presented) The non-volatile memory of Claim 40, further comprising: 

causing the session key to expire after a selected amount of time. 
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, 42. (Previously Presented) The non-volatile memory of Claim 40, further comprising: 

2 causing the session key to expire after a selected amount of usage. 

1 43, (Previously Presented) The non-volatile memory of Claim 38, further comprising: 

2 using a NTS file server as the file server. 

j 44, (Previously Presented) The non-volatile memory of Claim 38, further comprising: 

2 using a two way communication exchange between the proxy and the file server. 

1 45. (Previously Presented) An apparatus to establish identity in a file system, 

2 comprising: 

3 a proxy to receive a file request sent by a client to the file system, the proxy to 

4 forward the request to a file server; 

5 the file server to return a reply associated with the file request to the proxy, 

6 wherein the reply includes a file handle; 

7 the proxy to insert a session key into the file handle; and 

g the proxy to send the file handle with the session key inserted in the file handle to 

9 the client, the session key to be used in further requests to identify the client and the 

10 indicated file. 

1 46. (Previously Presented) The apparatus as in claim 45, further comprising: 

2 the proxy to receive, by the client, a second file request, the second file request to 

3 include the session key in a further file handle sent with the second request; 

4 the proxy to identify, in response to the session key, the client as having a 

5 permission to submit the another file request; 

(, the proxy to send the second request to the file server and not to send the session 

7 key witli the second file handle to the file server; and 

s the proxy to receive a further reply from the file server, and the proxy to send the 

9 further reply to the client. 

7 
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47. (Previously Presented) The apparatus of Claim 45, further comprising: 

the proxy to use the metadata in the file handle received from the client to 
eliminate a need for additional communication with the file server to establish file 
identity. 

48. (Previously Presented) The apparatus of Claim 45, further comprising: 

the proxy to encode the metadata in a form of a session key into the file handle, 
the session key expiring after a predetermined amount of time. 



1 49. (Previously Presented) The apparatus of Claim 45, further comprising: 

2 an NFS file system used as the file system. 

1 50. (Previously Presented) The apparatus of Claim 45, further comprising: 

2 a stateless protocol used by the file system. 

1 51 . (Previously Presented) An apparatus to establish identity in a file system, 

2 comprising: 

3 a proxy configured to receive a first file request sent by a client to the file system, 

4 the proxy further configured to forward the first file request to a file server; 

5 the file server configured to return a reply associated with the first file request to 
c the proxy; 

7 the proxy further configured to insert a session key into a file handle; 

s the proxy further configured to send the file handle with the session key inserted 

9 in the file handle to the client, the session key configured to be used in a second file 

10 request to identify the client and the indicated file; 

1 1 the proxy further configured to receive, by the client, a second file request, the 

12 second file request configured to include the session key in a second file handle sent with 

13 the second file request; 

14 the proxy Further configured to identify, in response to the session key, the client 
i s as having a permission to submit the second file request; 

S 
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the proxy further configured to send the second file request to the file server and 
not to send the session key with the second file handle to the file server; and 

the proxy further configured to receive a second reply from the file server, and the 
proxy further configured to send the second reply to the client. 

52. (Previously Presented) A method for establishing identity in a file system, 
comprising: 

receiving a first file request concerning an indicated file from a client, the first file 
request received by a proxy; 

forwarding the first file request from the proxy to a file server; 

determining that the client has a permission to have the request acted upon by the 
file system in response to a predetermined protocol; 

returning a reply associated with the first file request from the file server to the 
proxy, wherein the reply includes a file handle associated with the indicated file; 

inserting, by the proxy, a cryptographic information into the file handle; 

sending, by the proxy, the file handle with the cryptographic information inserted 
in the file handle to the client, the cryptographic information to be used in one or more 
requests to identify the client and the indicated file. 

53. (Previously Presented) The method according to claim 52, further comprising: 

receiving, by the client, a second file request by the proxy, the second file request 
including the cryptographic information in a second file handle sent with the second file 



identifying, in response to the cryptographic information, that the client has the 
permission to submit the second file request; 

sending the second file request to the file server and not sending the cryptographic 
information with the second file handle to the file server; and 

receiving by the proxy a second reply from the file server, and sending by the 
proxy the second reply to the client. 



9 
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j 54. (Previously Presented) The method according to claim 52, further comprising: 
2 causing the cryptographic information to expire after a selected amount of time. 

1 55. (Previously Presented) The method according to claim 52, further comprising: 

2 causing the cryptographic information to expire after a selected amount of usage. 

1 56. (Previously Presented) The method according to claim 52, further comprising: 

2 using a NFS protocol as the predetermined protocol. 

1 57. (Previously Presented) The method according to claim 52, further comprising: 

2 using as the predetermined protocol a two way communication exchange between 

3 the proxy and the file server. 

1 58. (Previously Presented) An apparatus to establish identity in a file system, 

2 comprising: 

3 a proxy configured to receive a file request for an indicated file sent by a client to 

4 the file system, the proxy further configured to forward the request to a file server; 

5 the file server configured to return a reply associated with the file request to the 

6 proxy, wherein the reply is configured to include a file handle; 

7 the proxy further configured to insert a cryptographic information into the file 

8 handle; and 

9 the proxy further configured to send the file handle with the cryptographic 

10 information inserted in the file handle to the client, the cryptographic information 

i i configured to be used in further requests to identify the client and the indicated file. 

1 59. (Previously Presented) The apparatus as in claim 5 S, further comprising: 

2 the proxy further configured to receive, by the client, a second request, the second 

3 file request to include the cryptographic information in a second file handle sent with the 
j second request; 

10 
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the proxy further configured to identify, in response to the cryptographic 
information, the client as having a permission to submit the second file request; 

the proxy further configured to send the second request to the file server and not 
to send the cryptographic information with Ihe second file handle to the file server; and 

the proxy further configured to receive a further reply from the file server, and the 
proxy to send the further reply to the client. 

60. (Previously Presented) The apparatus of claim 58, further comprising: 

the proxy further configured to use the metadata in the file handle received from 
the client to eliminate a need for additional communication with the file server to 
establish file identity. 



1 61. (Previously Presented) The apparatus of claim 58, further comprising: 

2 the proxy further configured to encode the metadata in a form of a cryptographic 

3 information into the file handle, the cryptographic information configured to expire after 

4 a predetermined amount of time. 

1 62. (Previously Presented) The apparatus of claim 58, further comprising: 

2 an NFS file system used as the file system. 

1 63. (Previously Presented) The apparatus of claim 58, further comprising: 

2 a stateless protocol used by the file system, 

1 64. (Previously Presented) An apparatus to establish identity in a file system, 

2 comprising: 

3 a proxy configured to receive a first file request sent by a client to the file 

4 system, the proxy to forward the first file request to a file server; 

5 the file server configured to return a reply associated with the first file request 

6 to the proxy; 
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the proxy further configured to insert a cryptographic information into a file 

handle; 

the proxy further configured to send the file handle with the cryptographic 
information inserted in the file handle to the client, the cryptographic information 
configured to be used in a second file request to identify the client and the indicated 
file; 

the proxy further configured to receive, by the client, a second file request, the 
second file request configured to include the cryptographic information in a second 
file handle sent with the second file request; 

the proxy further configured to identify, in response to the cryptographic 
information, the client as having a permission to submit the second file request; 

the proxy further configured to send the second file request to the file server 
and not to send the cryptographic information with the second file handle to the file 
server; and 

the proxy further configured to receive a second reply from the file server, and 
the proxy to send the second reply to the client. 

65. (Previously Presented) A method for establishing identity in a file system, 
comprising: 

receiving a file request concerning an indicated file from a client, the request 
received by a proxy; 

forwarding the request from the proxy to a file server; 

remrning a reply associated with the file request from the file server to the 
proxy, wherein the reply includes a file handle associated with the indicated file; 

inserting, by the proxy, metadata into the file handle; and 

sending, by the proxy, the file handle with the metadata inserted in the file 
handle to the client, a size of the file handle set to a sum of a length of the server file 
handle and a length of the proxy metadata, the metadata to be used in further requests 
to identify the client and the indicated file. 
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66. (Previously Presented) A method, comprising: 

receiving, by a proxy, a file request for a file sent from a client; 

forwarding the file request from the proxy to a file server; 

returning a reply associated with the file request from the file server to the 
proxy, wherein the reply includes a file handle; 

inserting, by the proxy, metadata into the file handle; 

sending, by the proxy, the file handle with the metadata inserted in the file 
handle to the client; and 

using, by the client, the metadata inserted into the file handle in a subsequent 
file request to identify the client and the file. 



1 67. (Previously Presented) A computer apparatus, comprising: 

2 a proxy configured to receive a client file request for a file and forward the 

3 file request from the proxy to a file server; 

4 the server configured to return a reply associated with the file request, wherein 

5 the reply includes a file handle; 

6 the proxy further configured to intercept the file handle sent from the server 

7 and insert metadata into the file handle to create a modified file handle; 

3 the proxy further configured to send the modified file handle with the 

9 metadata inserted in the file handle to the client; and 

10 the proxy further configured to receive the modified file handle from the client 

11 for a second file request For the file, wherein the proxy is further configured to use the 

1 2 modified file handle to eliminate a need for the proxy to generate one or more 

13 additional requests to the server that would be required to access the file if the 
i 4 modified fi le handle did not include the inserted metadata. 



13 



PAGE 14121 * RCVD AT 2/16/2010 1 :54:42 PM [Eastern Standard Time] * SVR:USPTO-EFXRF-5/34 * DNIS:2732752 * CSID: ' DURATION (mm-ss):05-54 



Hois 



PATENTS 
112056-0474 
P01 -2475.01 

REMARKS 

Claims 1-5 and 30-67 are in the case. 
Claim 1 is presented for discussion. 

Rejections U™lgr 35 U.S.C. 6103 

At Paragraph 6 of the Office Action, claims 1-5 and 30-67 were rejected under 35 
U-S.C. §1 03(a) as being obvious over Chandrashekhar et aL, U. S- Patent Publication 
2005/0033988 published on February 10, 2005 (hereinafter "Chandrashekhar"), and in 
view of Ryuutou et al., U.S. Patent Application Publication No. 2002/0083191 published 
on June 27, 2002 (hereinafter "Ryuutou"). 

Applicant's claimed novel and non-obvious invention, as set out in representative 

claim 1, comprises in part: 

1 . A method for establishing identity in a file system, comprising: 

receiving, from a client, a first Network File System (NFS) 
operation concerning an indicated file, the first NFS operation received by 
a proxy; 

forwarding the first NFS operation from the proxy to be received 
by a file server; 

returning a NFS file handle associated with the first NFS operation 
from the file server to the proxy in response to the file server receiving the 
first NFS operation from the proxy; 

inserting, by the proxy, metadata into the NFS file handle in 
response to receiving the NFS file handle from the file server, wherein the 
metadata is an encryption key; 

sending, by the proxy in response to receiving the NFS file handle 
from the file server, the NFS file handle with the metadata inserted in 
the NFS file handle to the client as a reply to the first NFS operation; and 

using, by the client, the metadata and the NFS file handle in a 
second NFS operation to identify the client and the indicated file. 

As an aside, in an interview conducted on August 27, 2009 and in the subsequent 
Amendment filed on September 8, 2009, Applicant discussed how neither 
Chandrashekhar nor Ryuutou disclosed an NFS file handle. As such, Applicant argued 
that neither Chandrashekhar nor Ryuutou failed to teach or suggest Applicant's claimed 
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ravel and non-obvious inserting encryption key metadata into an NFS file handle and 
then sending the NFS file handle M the enervation key metadata inserted in the NFS 
ate handle to the client as a reply to the first NFS operation. Applicant maintains this 
argument; however, in the interest of advancing prosecution and avoiding the delay in 
seeking appellate review from the Board of Patent Appeals and Interferences and/or the 
U.S. Court of Appeals for the Federal Circuit, Applicant respectfully presents an 
alternative argument. Applicant expressly reserves the right to present these contentions 
or variations thereof in any appellate procedures. 

Chandrashekhar discusses processing file requests sent by a client and received by 
a proxy using security applications to encrypt, decompress, verify, and decrypt network 
data by a server receiving the files from the proxy [0058; 0071]. Header policy 
information is determined, generated, and then stored on the filer server [0055; Fig. 4-5]. 
However, an y metadata added to a file is stripped off before the file is returned to the 
client [0038]. 

Ryuutou discloses, in relevant part as cited by Examiner, a client establishing an 
HTTP connection between the client and a proxy server by initiating a communication 
connection request [0072-0073]. A session ID is added to header information of an 
HTTP request [0067; see also Fig. 9 below]. Notably, Ryuutou explicitly states that 
session IDs are identifiers of sessions whose communications have been established 
[0069; see also Fig. 1 below (item 2: "DETERMINING WHETHER OR NOT 
CONNECTION IS ESTABLISHED ACCORDING TO IDENTIFIER WRITTEN IN 
REQUEST")]- 
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Applicant respectfully urges that ChandWshekhar, taken singly or in any 
combination with Ryuutou, does not disclose Applicant's claimed novel and non-obvious 

sending a NFS file handle with encryption key metadata inserted in the NFS 
file handle to a client. 

Applicant claims, in part, a proxy receiving from a client a first Network File 
System (NFS) operation concerning an indicated file and forwarding the first NFS 
operation from the proxy to be received by a file server. Applicant further claims 
returning a NFS file handle associated with the first NFS operation from the file server 
to the proxy in response to the file server receiving the first NFS operation from the 
proxy. Applicant further claims inserting, by the proxy, encryption key metadata into the 
NFS file handle. With that being said, after inserting (the encryption key) metadata into 
the NFS file handle, Applicant further claims sending a NFS file handle with encryption 
key metadata inserted in the NFS file handle to a client. 



Applicant respectfully argues that 
Applicant's claimed novel and non-obvious 
key metadata inserted in the NFS file handle 
Chandrashekhar may or may not disclose 
file handle, Chandrashekhar is explicit in 
the file is returned to the client (see 
below): 



Chandrashekhar does not teach or suggest 
sending a NFS file handle with encryption 
to a client. Specifically, while 

encryption key metadata into a NFS 
that the metadata is stripped off befo re_ 
at [0038] cited, in relevant part, 



nserting e 



stating 



s Chandrashekhar 



. . The meta-data is stripped of? before the file data/file attributes are 



returned to the client . . . (emphasis added) 



Accordingly, not only does Chandrashekhar 
non-obvious sending a NFS file handle with 
NFS file handle to the client, but Chandrashekhar 
Therefore, because Chandrashekhar explicil 



illy 



not teach Applicant's claimed novel and 
encryption key metadata inserted in the 

actually teaches away from doing so. 
teaches away from sending a NFS file 
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handle with encryption key metadata inserted 
Chandrashekhar fails to teach or suggest Applicant 1 
handle with encryption key metadata inserted in 



it Ryuutou 



Applicant respectfully argues that 
claimed novel and non-obvious sending a NFS 
metadata inserted in the NFS file handle to a 
or may not teach adding a session ID to header 
a session ID is an identifier of a session between 
communications have been started (see Ryuutou 



does not teach or suggest Applicant's 
file handle with encryption key 
client. Specifically, while Ryuutou may 
information, Ryuutou explicitly states that 
a client and a server whose 
at [0069] cited, in relevant part, below): 



The already stored session identifiers , .j 
mmrmini ca tions have been started . . .(emphasis added) 



In other words, while Ryuutou may or may not 
information, Ryuutou' s session ID is not em 
Applicant claims sending encryption key 
the client. As such, because Ryuutou's defm 
disclosure of being encryption key metadata, 
Applicant's claimed novel sending a NFS file 
inserted in the NFS file handle to the client. 



To reiterate: 

(I) Even if it is assumed arguendo that Chandrashekhar stores encryption key 
metadata in a NTS file handle, Chandrashekhar does not send the NFS file handle with 
encryption key metadata inserted in the NFS file handle to the client, because 
Chandrashekhar explicitly states that the metadata is stopped off before the file is 



returned to the client . Thus, if encryption ke; 
stripped off before the file handle is returned' 
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the NFS file handle to the client, 

s claimed novel sending a NFS file 
the NFS file handle to the client. 



are identifiers of sessions whose 



cryptioi 



teach adding a session ID_t o header 
m key metadata. In contrast, 

inserted in the NFS file handle to 
of a session ID does not include any 
Ryuutou fails to teach or suggest 
handle with encryption key metadata 



metadata is stored in a NFS file handle, but 
to the client, then the file handle cannot 



contain encryption key metadata. Therefore, Chandrashekhar fails to teach or suggest 
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nding a NFS file handle with encryption 
the client. 



Applicant's claimed novel and non^obvious sei 
key metadata inserted in the NFS file handle 

(II) Similarly, even if it is assumed arguendo that Ryuutou stores a session ID into a 
NFS File handle, Ryuutou does not send the N^S file handle with encryption key 
metadata inserted in the NFS file handle to the client, because Ryuutou explicitly states 

a aresinn TP is an identifier of a session b et w e en a c li ent and a server who se 
nnmmunications have been started . Thus, if a session ID is an identifier of a session 
between a client and a server whose communications have been started, then a session ID 
cannot be encryption key metadata. More specifically, if a session ID cannot be 
encryption key metadata, then sending a NFS file handle with a session ID inserted in the 
NFS file handle to the client is demonstrably different than sending a NFS file handle 
with encryption key metadata inserted in the NFS file handle to the client. Therefore, 
Ryuutou fails to teach or suggest Applicant's claimed novel and non-obvious sending a 
NFS file handle with encryption key metadata inserted in the NFS file handle to the 
client. 



Chandrashekhar a 



Accordingly, Applicant respectfully injges 
any combination with Ryuutou, is legally 
invention obvious under 35 U.S. C §103- 
in any combination, fails to teach or suggest Applicant 1 
sending a NFS file handle with encryption key 
handle to a client. 



Applicant's Interpretation of the Prior Art 



Applicant's interpretation of the prior 1 art references was derived, in part, from the 
following excerpts: 

Chandrashekhar 

[0038]. ..The meta-data relates to keyjmanagement, length of the original 
file/dataset, whether tine file was compressed prior to encryption or not, 



that Chandrashekhar, taken singly or in 
to render the presently claimed 

and Ryuutou, taken singly or 
5 s claimed novel and non-obvious 
metadata inserted in the NFS file 
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integrity checks for file data. The meta-t 
data'*"'* attributes are returned to the 
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■data is stripp^ off before Has file 
(emphasis added) 



Rvuutou 

moi7] a communication r.nnnection i Unest is re ceived from a cl ient, 
whether or not a communication connection corresponding to a series of 
communications is established is determined according to ^ identifi er 
written in the communication co nnection request and the requested 
communication is connected to a particular relay device as a relay 
destination of an established communication connection, i f the 
communication connection is established, (emphasis added) 

[0057] FIG. 6 is a flowchart showing the process of a communication 
connection management method in this] preferred embodiment- In FIG- 5, 
when a new communication connection to a g ateway is established jn 



wn en a new commumcaLiun wm n ^iiuu m " r^..^., x^. — — 

correspondence with the initial communic ation connection request withm 



^Vl session! and * session TP is set , its contents are stored in a memory 
(table) not shown... (emphasis added) 



[0069] The already stored session 
identifiers of sessions whose. 



communications 



numbers of connections established for the sessions respectively, 
(emphasis added) 



[0072] As explained with reference to 
the session ID ZZZ are set by the proxy 
communication connection request - Tne 
the header information. . .and returned, 
added) 

[0073] At this time, ZZZ as the session ID is added b etween B and C in 
the header information shown in FIG. 10 - As a method adding a session 
ID, a method such as Netscape Cookie, with which a browser side can 
recognize and store, for example, data 1 that is additionally described in a 
HTTP header, is used, (emphasis added) 



s and connection numbers are 
n started, and 



FIG. 9, the session number S4, and 
in correspondence with this 
newly set session ID is added to 
to the client side, (emphasis 



[0074] A reply including header information to which a session ID is 
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E1021 



added is returned from a proxy side to a PC 
that header information including the session TP. 
information in the second and subsequent 
requests , (emphasis added) 



Conclusion 



All newly proposed claims and/or propc 
fully supported by Applicant's specification. 
All proposed independent claims are 
All proposed dependent claims are 
proposed independent claims, and therefore in 



sed claim amendments are believed to be 



believed to be in condition for allowance, 
believed to be dependent from allowable 
;ondition for allowance. 
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side as described above, so 
can be used as the header 
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